[class.default.ctor, class.copy.ctor, class.copy.assign] No code font for "is constexpr"#6620
[class.default.ctor, class.copy.ctor, class.copy.assign] No code font for "is constexpr"#6620Quuxplusone wants to merge 1 commit intocplusplus:mainfrom
Conversation
Quuxplusone
changed the title
constexpr)
This was made false by P2448R2 IIUC. |
eisenwave
added
needs rebase
source/classes.tex
Outdated
| \end{note} | ||
| The implicitly-defined\iref{dcl.fct.def.default} | ||
| constructor is \keyword{constexpr}. | ||
| An implicitly-defined\iref{dcl.fct.def.default} constructor is |
There was a problem hiding this comment.
As I said before, changes to [class.copy.ctor] and [class.copy.assign] were probably incorrect. Would you mind to rebase the branch and only preserve changes to [class.default.ctor]?
source/classes.tex
Outdated
| An implicitly-declared copy/move assignment operator is an | ||
| inline public member of its class. | ||
| inline public member of its class, | ||
| and is implicitly constexpr if it is constexpr-suitable. |
There was a problem hiding this comment.
At this point every non-coroutine function is constexpr-suitable, and an implicitly declared copy/move assignment operator is never a coroutine, so indeed the phrase if it is constexpr-suitable can be eliminated.
The point of this change — to replace "is constexpr" with "is implicitly constexpr" — remains, AFAICT.
(Also, Note 1 in [dcl.fct.def.default] seems misleading: it should probably say that other functions explicitly defined as defaulted are not implicitly constexpr.)
… for "constexpr" ...in "is constexpr" or "is a constexpr function," since a function can be "a constexpr function" ([dcl.constexpr]/2) without using the `constexpr` keyword in the source code.
Quuxplusone
force-pushed
the
constexpr-suitable
branch
from
1b37c17 to
4036f1e
Compare
source/classes.tex
Outdated
| \begin{note} | ||
| An implicitly-declared default constructor has an | ||
| exception specification\iref{except.spec}. | ||
| implicit exception specification\iref{except.spec}. |
There was a problem hiding this comment.
I think this is still necessary, but it looks like the term of art is "implied exception specification" (e.g. [class.copy.ctor] Note 6), not "implicit exception specification." So I've removed this change from this PR. I might open a different PR to clean up this phrase, later, but have no plans to do it immediately.
Quuxplusone
changed the title
constexpr)…xpr-suitable" This starts by reverting commit 79aef51, and then un-teletypes the word `constexpr` in "is a `constexpr` function" in the last place it's currently teletyped (after cplusplus#6620, that is).
3 participants
Just throwing this over the wall, in hopes that if any of these are editorial improvements they'll be taken up individually.
Right now the text is pretty inconsistent about "X is constexpr"/"X is
constexpr", but I think the former is better. I'm also pretty sure that a function that isn't constexpr-suitable cannot possibly be constexpr, hence the biggest diff below.